1 Introduction

The MyID^® Derived Credentials Notifications Listener is designed to allow the derived credential to be updated when the deriving credential is updated.

The system that issued the deriving credential will send notifications which the listener will pick up and process.

1.1 Installation

To enable the listener for Derived Credentials, select the Derived Credentials Notifications Listener option when installing MyID.

You can install the web service on the MyID web server, or on another server that has DCOM proxies that link it to the MyID application server – for information on setting up DCOM proxies, see the Split deployment section in the Installation and Configuration Guide.

1.2 Security

The web service is installed on the server with no access permissions applied – this is because it is a privileged web service and should not be left exposed. Before using the web service, you must use Internet Information Services (IIS) Manager to set up appropriate permissions for the DCNotificationListener virtual directory.

1.3 WSDL

You can obtain the WSDL for the web service by browsing to:

http://server.example.com/DCNotificationListener/Listener.svc?singleWsdl

where server.example.com is the name of the server on which you have installed the Derived Credentials Notifications Listener web service.

See also section 9, WSDL reference.

1.4 PIV-D Kiosk and SSRP

There are two ways to initiate the issuance of a Derived Credential in MyID:

• PIV-D is a fully-managed solution that uses the MyID Self-Service Kiosk application to interrogate a PIV card to enroll the user's credentials.

  PIV-D devices are managed by the FASCN and UUID of the source PIV card.

• SSRP is a browser-based solution that uses an SSL certificate to enroll a user. SSRP is a more generic solution and is suitable for non-PIV derived credentials.

  SSRP devices are managed by the hash of the certificate used to enroll the user. The API methods for handling this all end with OfCertificate.

It is recommended to use only one of these mechanism on a deployment. Where both are used, and there is no clear distinction between which mechanism a user may have used, it is recommended that when a lifecycle event occurs that both the FASCN- and Certificate-based method are invoked. For example, if a credential is no longer trusted, and the user has a FASCN and an SSL-capable certificate, invoke both CessationOfTrust and CessationOfTrustOfCertificate.